Computer systems and other types of consumer electronic devices are commonly linked to each other and to peripheral devices using a myriad of different types of cables and connectors. As these devices grow in number and variety, their cables and connectors can often become quite cumbersome to work with. Accordingly, efforts are underway to develop technologies allowing hardware connections to be replaced with wireless ones.
One such technology is the Bluetooth technology. Bluetooth is the code name for a technology specification for short-range radio links that will allow the many proprietary cables that connect devices to one another to be replaced with short-range radio links.
The Bluetooth technology is based on a high-performance, yet low-cost, integrated radio transceiver. For instance, Bluetooth transceivers built into both a cellular telephone and a laptop computer system would replace the cables used today to connect a laptop to a cellular telephone. Printers, personal digital assistants (palmtop computer systems, hand-held devices and the like), desktop computer systems, fax machines, keyboards, joysticks and virtually any other digital device can be part of a Bluetooth system. Bluetooth radio technology can also provide a universal bridge to existing data networks and a mechanism to form small private ad hoc groupings (“scatternets” or “piconets”) of connected devices away from fixed network infrastructures.
One issue that arises with the introduction of Bluetooth technology is the treatment of “legacy applications;” that is, those applications developed before the advent of Bluetooth and still residing on a Bluetooth-enabled device. These legacy applications are predicated on the use of actual (physical) serial cables, such as RS232 or similar serial cables, to connect the server and client devices. However, as described above, the Bluetooth technology replaces such cables with wireless connections. To address the issue of legacy applications, the Bluetooth specification (“Specification of the Bluetooth System, Core,” version 1.0B, dated Dec. 1, 1999, herein incorporated by reference as background) defines protocols and procedures that can be used by Bluetooth devices to emulate serial cables.
Prior Art FIG. 1A is a block diagram illustrating the protocol layers and applications residing on Bluetooth-enabled devices A 10 and B 20 in one embodiment. For Bluetooth-enabled devices, the protocol layers are described by the Bluetooth specification referenced above. In general, baseband 19 and 29 carry out baseband protocols and other low-level link routines, and logical Link Control and Adaptation Protocol (L2CAP) 18 and 28 support higher level protocol functions.
Because they pre-date Bluetooth, legacy applications 12 and 22 are not configured to implement Bluetooth procedures for setting up emulated serial cables. Accordingly, RFCOMM 16 and 26 provide a transport protocol for emulation of serial ports over L2CAP 18 and 28, respectively. Serial port emulation blocks 14 and 24 are the entities that emulate serial ports and/or provide an application program interface to legacy applications 12 and 22, respectively. Thus, legacy applications 12 and 22 can run on devices A 10 and B 20, respectively, and communicate using the “virtual” serial ports as if there were a real serial cable connecting the devices.
It is expected that the number of Bluetooth devices will increase significantly, and that the number of services (e.g., applications) that can be provided over Bluetooth links will also increase significantly. To help users of Bluetooth devices sort through the increasing number of services and applications that will become available, procedures are being developed to standardize how services are to be located and identified on Bluetooth devices. These standards and procedures are described in the above-referenced Bluetooth specification and summarized below.
The protocol stack used by Bluetooth devices includes a Service Discovery Protocol (SDP) that is used to locate (discover) services and applications that are available on a Bluetooth-enabled device, or that are in the vicinity of such a device. SDP provides direct support for search inquiries by service class and/or service attributes, and also supports service browsing. Search inquiries by service class are for identifying whether a known service is available, and search inquiries by service attributes are used for identifying whether services having particular characteristics are available. Service browsing is used for general searches to identify, for example, what services of a particular type (e.g., news, reference, gaming, etc.) are available.
Service discovery can be initiated by either a master device or a slave device. Generally, in the context of service discovery and service use, the terms “server” and “client” are used. “Server” is used to refer to a device with services and applications waiting for a connection from a client device, and “client” refers to a device that initiates (requests) a connection to the application or service. A server device is also sometimes called an “acceptor,” and a client device is also sometimes called an “initiator.”
The Bluetooth service discovery process provides the means for client applications to discover the existence of services provided by server applications, as well as the attributes of those services. The attributes of a service are maintained by the server in a service record. The attributes of a service include the type or class of service offered, and the protocol information needed to utilize the service. Significantly, the attributes of a service should also include a service name, which is a text string containing a user-friendly (e.g., human-readable) name for the service.
An issue with regard to legacy applications (e.g., 12 and 22 of FIG. 1A) is that they are not able to participate in the Bluetooth service discovery process. As mentioned, legacy applications 12 and 22 pre-date Bluetooth, and thus are not configured for the Bluetooth service discovery process.
Regarding service records for legacy applications, the Bluetooth specification (specifically, Section 3.1.3 of the Serial Port Profile) states: “All services/applications reachable through RFCOMM [that is, legacy applications] need to provide an SDP service record that includes the parameters necessary to reach the corresponding service/application . . . . In order to support legacy applications running on serial ports, the service registration must be done by some helper-application, which is aiding the user in setting up the port” (emphasis added).
Prior Art FIG. 1B is a table exemplifying a service record 50 for an available service or application, in particular for a legacy application. “ServiceClassIDList” identifies the type of service (e.g., serial port) represented by the service record 50. The “ProtocolDescriptorList” specifies the protocol stacks (e.g., L2CAP and RFCOMM) that may used for the service. The “ProtocolSpecificParameter0” represents the RFCOMM server channel of the legacy application. The “ServiceName” is a text name displayable to and readable by a user.
The Bluetooth specification defines most of the values in service record 50 for a legacy application, with the notable exception of the service name (ServiceName). Other than the reference to “some helper application,” the Bluetooth specification provides no guidance regarding how the service name for the legacy application is to be provided for service record 50.
The service name represents an important piece of information, enabling a user to readily identify an application and distinguish it from other applications, in particular when browsing through the large number of services and applications expected to be available in a Bluetooth environment. Thus, it is desirable to have a standard approach for providing the service name for a legacy application, so that the legacy application is readily identifiable to the user, as well as to simplify the service discovery process for the user.
One solution is to display to the user a pop-up window (or other graphical user interface), allowing the user to enter information to complete service record 50 for each legacy application. However, this solution can be problematic if the user does not know or understand what information is needed for service record 50. This solution may also be time-consuming and inefficient when information for a large number of legacy applications needs to be entered.